CS349W Interactive TreeMap
=Interactive TreeMap - Juho Kim and James Mao= http://www.finviz.com/map.ashx?t=sec Finviz treemap is an interactive financial visualization tool for the stock market. Sectors are visualized in different sizes and shades, showing how well they are doing in the market. Why is this interesting? * Learn the technique in visualizing a large amount of data. * See how panning and zooming are implemented by Javascript. * See how server and client divides work - this interaction is really server-centric. * It works like Google Maps, but not obfuscated. What is the overall structure of the interaction? * Canvas and navigation panel exchange data - Canvas: treemap browsing - Navigation panel: info. display and search * Type of interactions - Move around with mouse drag - Open with mouse double-click - Zoom with mouse wheel - Info. display on mouse over What is the role of Javascript (event handlers, AJAX requests, etc.)? * Events on the canvas * onmousedown = StartMove * Turn on flag to indicate dragging(viewMove) * Store current Client X/Y * Start a timer to figure out whether this is a drag or a single click * onmousemove = ProcessMove * If dragging, then move divs of the tiles. * onmouseup = StopMove * If single click, then zoom one level at stored Client X/Y * ondblclick = Open in the new window (chart) * onmousewheel = MouseWheel * Zoom in/out at the current mouse position What parts of the interaction happen in the browser and what parts require server interaction? Panning, zooming, and displaying summary data (i.e. information about a ticker when clicked) are all handled in the browser. Server is queried to load new tiles at different zoom levels when not previously loaded or when the data changes. This site takes the approach of doing all the rendering and data processing on the server side. * Pros: Same look and feel across browsers; works on slower computers; since images are server rendered and cached (a snapshot is cached forever), can be embedded into blogs; easier to get licensing from data sources (i.e. exchanges do not like it when you provide data to clients without exchange agreements -- usually lots of legal hassle) * Cons: Massive amounts of bandwidth required, lots of storage needed on the server There are other splits between server and client imaginable. For example, Canvas element and raw data. Instead of hosting an image for others to link to, let them download the image. * Pros: Less bandwidth; less storage on server * Cons: Less traffic for website due to less Google link love from blogs; possible browser incompatibilities Data Fetching If data is fetched dynamically from the server, what is the granularity of those patches? Graphic tiles are fetched in 300x300 PNG blocks. There are four zoom levels. * Level 0: 2x3 * Level 1: 4x6 * Level 2: 8x11 * Level 3: 16x22 Are there any special techniques for hiding latency, such as prefetching? No prefetching or other latency hiding techniques are done and latency is clearly visible. Load times are at least a second at each zoom level, sometime Are there things about the facilities of the Web that made this interaction either easy or hard? Did the interaction have to contort itself to get around problems with the Web? The lack of pixel level interaction and the lack of a canvas abstraction makes this interaction hard. Lacking those facilities, the app must render the tiles on the server and then transfer them. The result is an application that has to transfer large amounts of data and do a lot of rendering that can all be easily handled by the client's graphics libraries. If this were a client-server app, the server only needs to provide the price, last change, number of shares outstanding, ticker name, and company name to the client. For each update, the server only needs to provide a list of the latest prices (500 floats), 2KB of data. Instead, it costs about 500KB of data for each screen update (for a pan and zoom operation, this quickly adds up to several MB). Are there improvements to the Web that would have made this interaction easier to implement, or that would have allowed a more powerful interaction? * Browser incompatibilities (IE bugs) make it difficult to implement interactions. Events are registered in Javascript, instead of HTML. * Using the Canvas element in HTML can probably lead to more powerful interaction, since pixel-level access is possible. Are the techniques used in this interaction relevant for a broader class of interactions? Yes, the ability to zoom in/out, pan, on a large canvas is a common interaction (e.g. Google Maps, zoomii.com, etc.).